1. Field
The subject matter disclosed herein relates to the processing of network packets. In particular, the subject matter disclosed herein relates to processing network packets in a network processing environment.
2. Information
Network routers typically employ network processing elements to process network packets received at ingress communication ports for forwarding to egress communication ports according to one or more network policies. A router may comprise multiple network processing elements that transmits network packets through links coupling the network processing elements. For example, a first network processing element may classify a received network packet and then forward the network packet to a second network processing element. The second network processing element may then associate an egress port with the network packet. In conjunction with forwarding network packets from one network processing element to another in a router, individual network processing elements may forward control information on a per-packet basis (e.g., meta data or control information representative of a classification or egress port number).
Network processing elements—such as network processors, classification, traffic management, security, and accounting co-processors, or even software modules within a single processor—within a single network element (e.g., a router), typically employ some form of per-packet communication to efficiently process packets. For example, in a multi-blade chassis-based router, where each blade contains a classification co-processor and a network processor, the classification co-processors typically communicate the result of each packet's classification (e.g., a flow ID) to a corresponding network processor. The network processor typically then marks and polices the packet. Similarly, for any packet arriving on one blade and destined for a port on another blade, the ingress network processor typically communicates the outgoing port number to an egress network processor.
To communicate control information or meta data on per-packet basis, one solution is to annotate each packet with the desired information. This annotation is typically done by prepending or appending the packet with the appropriate meta data or control information. For example, in a multi-blade chassis-based router, a classifier co-processor typically prepends flow ID information on each packet before forwarding the packet to a network processor. The network processor could then extract the flow ID and subsequently prepend the outgoing port number before forwarding the packet to an egress network process across the backplane of a chassis.
Simply prepending packet annotations does not, however, address providing type identification. Two common solutions are to use either a self-identifying list of annotations or a fixed-format list of annotations. To create a self-identifying list of annotation, each annotation in the list typically contains a canonical type and a length field along with the actual value of the annotation. This so-called type-length-value (TLV) approach has the property of being self-identifying since each annotation can be fully identified by the type field. New annotations can be added because the length field allows older network processing elements to ignore unknown types. Fixed-format list of annotations typically determine a canonical position in the list for each possible type of information communication. No type or length information may be required because each of the network processing elements agrees on the single fixed-format.
TLV annotations, while flexible, are not efficient to process or transmit. TLV annotations are not efficient to process because they require a linear search of the annotation list to find the particular annotations (types) of interest. Moreover, the entire TLV list must be completely searched to find the start of the actual packet data. TLV annotations are not efficient to transmit because the type and length fields occupy bandwidth. If the representation of the actual values is small compared to the type and length fields, considerable bandwidth would be devoted to the transmission of the type and length fields.
Fixed-format annotations, while efficient to process, are not necessarily efficient to transmit and are also not flexible. With transmission of fixed-format annotations, there is the potential of transmitting unused fields. If, for example, two network processing elements only share one type of information, they still must transmit all of the fixed-format fields, including the unused fields. One solution would be to configure the communication between each pair of network processing elements with its own unique fixed-format. While this would solve the transmission inefficiency, it imposes a processing inefficiency and, worse yet, is intractable for ASIC-based networking processing elements.